Copyright: Copyright© 1994-1995 TMS (Int'l) Ltd.
Citation: The Mandelbrot Set (International) Ltd.


Contents
 Contents: 'Using the Windows API' - (VBITS London Jan 31st to Feb 2nd 1995)

Introduction

About... This Presentation

About... The Mandelbrot Set (International) Ltd.

The About... Application

The Point

Required Files

The 'Custom' DLL

The Blowup Application

The Point

Required Files

The 'Custom' DLL

Other

The 'Message Blaster'

The Tools We Used

Other Interesting Stuff

Licensing & Disclaimer

TMS @ VBITS


Licensing & Disclaimer

In the following:

VBITS is an acronym of 'The Visual Basic Insiders Technical Summit'.

TMS is an acronym of 'The Mandelbrot Set (International) Ltd'.

Usage of this material (License)

This 'material', the presentation notes and all binary/text files provided as an integral part of any talk or presentation given at this VBITS event (or as separate demonstration examples) by any TMS personnel are copyright © TMS 1994,1995. All rights reserved. No part of this presentation, or associated materials may be reproduced in any shape or form without the direct and written consent of TMS (see following note on source code). Failure to comply with these terms will result in prosecution to the maximum extent allowable under the law. Exceptions: Any source code provided by way of demonstration code may be utilized by the VBITS LONDON delegate to whom it has been given as part of a 'delegate/conference pack' providing that the source itself is not distributed, i.e. demonstration code made executable may be freely distributed, however, source code may not.

Disclaimer

TMS accepts no responsibility for the correctness/robustness of any of the materials provided at this VBITS event. An attendee using any of our code does so entirely at his/her own risk.


The 'point' of blowup
 The Point Of Blowup

The 'point' of blowup

In-brief. Blowup demonstrates how to use the API. The demonstration application creates a window that 'blows up' somewhat like the windows in Windows '95 do. The blowing up effect, or a variation on the same theme, is applied to the window when it is iconised or restored. For best results view this demonstration on a 'real' monitor, i.e. not an LCD (even TTF) display - the graphics are very fine and fast and only a real CRT will do them any justice. Both effects are instigated by Windows in that the application traps a WM_WINDOWPOSCHANGING message using a sub-classing VBX called 'message blaster'. The processing of this message actually causes the effect. A single routine called TMSExplodeForm, which uses a variety of Windows' API calls, is used to produce the effects themselves. Additionally, blowup shows how a standard API may be used from Visual Basic in a novel way and provides an alternative version of this standard API in a custom DLL (source included).

'Blowup' shows, as this is what our little talk was about, how to interact with the Windows' API. Blowup however goes further than this as it also shows you how to call your own API, i.e. how to call a DLL routine, written in 'C', that you've produced. That API is called nGetWindowPos(). This function resides in an DLL called, simply, DLL.DLL!! Here's the Visual Basic declaration for this function:

Declare Function CopyWP1 Lib "DLL.DLL" Alias "nGetWindowPos" (t As WINDOWPOS, ByVal l As Long) As Integer

We've used blue text to show Visual Basic keywords. Note that you may have to 'path' your DLL into a different location, e.g. you may have to do something like - "C:\VBITS\DEMOS\DLL.DLL" to the DLL name.

Blowup also shows us that the 'core' API is nearly good enough - see lstrcpyn() for more on this, and that there is a core API that actually is good enough - hmemcpy(). Note that this subroutine is NOT mentioned in the Windows API Help file (the Visual Basic declares help file).

Aliases

Note that the function nGetWindowPos() is the REAL name of the function within the TMS DLL. However, our application 'knows' the function by another name - CopyWP1. This is simply a handy alias to use as we have also aliased lstrcpyn() and hmemcpy() to be CopyWP2 and CopyWP3 respectively. In the source you may use whichever routine you like (although lstrcpyn() won't work correctly) by simply uncommenting/commenting a line of code in the routine MsgBlaster1_Message in the module frmMainForm. Search for the hash or 'pound' sign ('#') to find these lines more easily.

See Also

The Custom DLL


TMS Tools v1.1

TMS Tools version 1.1 is a collection of both pre and post development tools aimed entirely at the experienced Visual Basic programmer. Designed by professionals for professionals, ‘tools’ provides post-mortem debugging, tracing, code generating capabilities and ‘during development’ monitoring/stressing capabilities. Using ‘tools’ improves the quality and correctness of your code/application dramatically and easily.

"TMS Tools is a set of utilities that will help professional VB developers write better, more robust programs" - PC Magazine, August 1994.

The main tool in the toolkit is 'the AutoCoder'. This tool allows you to insert 'standard' templates into your code - three are supplied and any number more may be created using AutoCoder's own macro language. Templates may configured to do almost anything - even handle errors maybe!? An example 'error handling' template is provided. Templates are 'team safe'. For an example of the templating provided by AutoCoder see the Visual Basic source code used in the demonstrations.

'Tools v1.1' is a sub-set of some of the current development tools used, and developed by, TMS development teams. TMS took some of their most useful tools and created the current tool set from them. The toolkit currently sells for just £99 (ex-VAT). The toolkit is sold by TMS itself (see 'About The Mandelbrot Set' for contact details) and also by Grey Matter (Tel: 0364 654100) and QBS Software (Tel: 081 9944842).


The custom DLL
 The 'Blowup' Custom DLL

The DLL DLL (no, it's not a typo!)

The DLL 'special' to this demo is called DLL.DLL. It really contains just one function, and here it is:

BOOL __export FAR PASCAL nGetWindowPos(LPWINDOWPOS tDest, LPWINDOWPOS tSrce)

{

    *tDest = *tSrce;

    return TRUE;

}

To really USE the API it is always a good idea to have an idea as to how an actual API is written. The nGetWindowPos() function defined above is a real function. It's written in 'C', as are most APIs/other-DLL-functions. For you none 'C' programmers, here's an explanation of the code.

The first line declares the function, in fact this is a defining declaration as the function's really here. This function returns a BOOL, i.e. a boolean result (True or False). It is exported - this means that it is callable from outside of this library. It is FAR PASCAL. This means that the code (in a 16 bit world) is 'a far distance from your calling code', i.e. it lives in another code segment. The PASCAL means that it has the PASCAL calling convention. All DLL functions callable from Visual Basic must be compiled using this convention. When a routine is defined as 'PASCAL' it means that it takes a fixed number and type of arguments (it means some more as well but all that is irrelevant here). It receives two parameters which are called tDest and tSrce respectively. The 'type' of these two parameters is the same - LPWINDOWPOS. An LPWINDOWPOS is a far pointer to a WINDOWPOS structure, or put more easily, it is the address in memory of an instance of a 'type' called WINDOWPOS. This data structure is located outside of our 'near' address space, i.e. it's in someone else's data space.

Now comes the body of the function. The '*' means dereference the address (pointer) and give me the object at the end of the address. One object is therefore being assigned to the other - simple! Lastly, the function returns TRUE to the caller - note that it always returns TRUE.

The Problem With Visual Basic

Now, you could rewrite the 'C' function above in Visual Basic like this (couldn't you?):

Type WINDOWPOS

    ' Stuff

    ' in

    ' here

End Type

Sub SomeSub

    Dim a As WINDOWPOS

    Dim b As WINDOWPOS

    Debug.Print nGetWindowPos(a, b)

End Sub

Function nGetWindowPos(a As WINDOWPOS, b As WINDOWPOS) As Integer

    a = b

    nGetWindowPos = True

End Function

So why didn't we?

Well the problem is that 'things' are not as simple in 'blowup'! One of the WINDOWPOS structures we want to access , in fact it's the source WINDOWPOS, is not available to Visual Basic. Why not? Because all we have to access it by is its address! The WINDOWPOS we're interested in is passed to us by Windows as an address! Visual Basic doesn't have a pointer type so - we cannot use the pointer passed in! We might have been able to use the 'core' API 'lstrcpyn()' (to which there is a handy declare in the Windows 3.1 declares help file) but in this case we cannot. We can however use another 'core' API called 'hmemcpy()' (to which there is NOT a handy declare in the Windows 3.1 declares help file).

See Also

How lstrcpyn and hmemcpy work

TMS


About...

The Mandelbrot Set (International) Ltd.

    How to contact us

The Mandelbrot Set (International) Ltd (TMS) is a British based (though international), Windows-only software house specializing in Visual Basic development, particularly in a client/server environment.  Our core business is the provision of a range of quality software solutions and services to our mainly ‘blue chip’ client list.  This includes supplying very experienced, high quality software developers on a contract basis.  We firmly believe we are the top Visual Basic specialist software house in the UK. TMS:

» Is the company behind the very successful 'TMS Tools' Visual Basic programmer's toolkit.

» Is a Microsoft Solutions Provider.

» Has been a Visual Basic 4.0 early beta technical test site since the summer.

» Has Microsoft Visual Basic Certified Professionals on staff (our aim is to have all staff fully certified at all times).

» Is an active participant in the Visual Basic User Group (UK).

» From Q1 '95 - will have a full range of Visual Basic training courses  available (ranging from management seminars and strategic briefings, to introductory, intermediate and advanced programming courses).

We like to think of ourselves as educators rather than just trainers. Our courses and general 'knowledge transfer' approach are built on our real, and proven, record of producing successful software developments using Visual Basic, we are not just another trainer paraphrasing the manual, NOTE: We do this stuff for real and have to deliver real applications on time and to budget. We understand, and can separate, academic niceties from business realities! Nobody does Visual Basic education like us!

If you require consulting services (ranging from in-the-know high level technical strategy to nasty, low level technical troubleshooting and bug hunting) or software development staff on a contract basis to enhance the quality of your development effort, please do not hesitate to contact us - you won't be sorry you did.

We would be happy to provide potential clients with references, should you require them.

See Also

How to contact us


How to contact us

You may contact us by any of the following means:

We are here!

Email:

Mark Sewell

Via Compuserve	- 100337,772

Via the Internet	- 100337.772@Compuserve.com

Peter J. Morris

Via Compuserve 	- 100016,2751

Via the Internet 	- 100016.2751@Compuserve.com

Telephone (+44 if outside the UK) :

0451 861212 - Main switchboard.

0941 118035 - Mark Sewell - Managing Director. Direct line.

0941 117534 - Peter J. Morris - Technical Director. Direct line.

0941 117488 - The 'TMS Direct'  Messaging Service (Leave a message and we'll call you back).

Fax (+44 if outside the UK):

 0451 861122

Mail:

Mandel House, Nostle Road, Northleach, Gloucestershire. GL54 3PF. England.


 This Presentation

The Presenter

This presentation on using the Windows' API from within Visual Basic is brought to you by The Mandelbrot Set (International) Ltd. (TMS). Your presenter is Dr. Peter J. Morris - the Technical Director of TMS and author of the best selling book "Windows - Advanced Programming & Design", 908 pages of 'C' and assembler code for hard-core Windows' programmers (Published by Butterworth Heinmann Ltd. ISBN 0-7506-0636-3). The presentation is original and was written for VBITS London (event organized by FTP. 'Faucet Taps and Plumbing', or as we like to call them 'Jammed Faucet and the bathroom fittings'). Please see the section entitled 'Licensing & Disclaimer' before using any of the demonstration applications.

The Focus

The Windows' API is probably the most under utilized Visual Basic add-in every created. The reason for this is mainly one of complexity. Using the API seriously is a hazardous game at the best of times. The API is also, in comparison with normal Visual Basic development, under productive, i.e. it takes a lot of code to do something relatively simply.

This talk aims to show you why an investment in learning all about the API is worth it. It will also try to convince you that some wonderful things can be achieved with very little effort and will try to explode the myth that "the API is hard". It's not hard, it's just BIG!

The Code

Please note the following important points regarding the demonstration code:

The code has error handlers, as part of TMS's quality and coding standards all code that comes out of TMS MUST be to a certain standard, irrespective of whether or not it's being used simply as a demonstration - these demos were even Beta tested believe it or not! Sometimes you may feel that a piece of code is being obscured by an error handler, i.e. that a 'one liner' has about 20 additional lines of code around it to handle potential errors, alternatively you may feel that the 'one liner' in question cannot fail - Well, practically any line of code could fail, and, as we've stated, we have to put these in so simply remove them if they're 'in the way'. Please note that we have not, as a rule, tested the result of calling into the API. Again, this is something we would normally do but decided, and were able, to leave this testing out of the demonstration code - we hope this has made the demonstration code clearer for you.

Tip:

All the 'meat' within any routine is contained bewteen line marked:

' ========== Code Starts.==========

' ========== Code Ends  .==========

Further Information

TMS provides many Visual Basic related services to the IT industry (see About TMS) and would be happy to talk with you about your Visual Basic, or other Windows' programming requirements.

Other Information

TMS are also talking on 'Team Programming' using Visual Basic at this VBITS event. This talk will be presented jointly by Peter J. Morris & Mark Sewell - TMS's Managing Director.

See Also

Getting More Information


The 'point' of the About... box application
 The Point Of The About... Box Application

The 'point' of About

In-brief. 'About' demonstrates how to use the API. The demonstration application creates a two stage about box, i.e. a simple about box followed by a 'System Info' type secondary box. The application uses a wide variety of APIs to interrogate Windows for the necessary information required to build a decent 'About Box'. Some of these APIs are encapsulated in a TMS DLL called ABOUTDLL (source NOT provided) whilst others are simply 'standard' Windows' APIs. Note that ABOUTDLL.DLL was not written especially for this VBITS event and is a 'system' DLL used by TMS programmers.

'About' shows, as this is what our little talk was about, how to interact with the Windows' API. The About application itself is really the mother of all About boxes containing information about the system not even available through using the API - before you get too excited here, please note that most of the 'interesting' about box information in About comes from a TMS DLL the source code for which is not provided - sorry, the DLL used is  an internal TMS DLL used in live applications.

The TMS DLL is declared in the application like this:

Declare Function bAboutCall Lib "ABOUTDLL.DLL" (ByVal nServiceID As Integer, lpStruct As Any) As Integer

We've used blue text to show Visual Basic keywords. Note that you may have to 'path' your DLL into a different location, e.g. you may have to do something like - "C:\VBITS\DEMOS\ABOUTDLL.DLL" to the DLL name.

The DLL function

The single DLL function exported by ABOUTDLL is bAboutCall, however this function is called many times from within the application and provides all sorts of different data. How is this done?

The DLL is written a little like the Visual Basic run-time system DLL (VBRUN100.DLL, VBRUN200.DLL, VBRUN300.DLL etc). These DLLs too have just one entry point in them (not counting interrupt handlers etc). However both they and bAboutCall actually 'map' to many functions located within (non-exported) the DLL itself. In the case of bAboutCall an internal function is called based upon nServiceID (the first parameter to bAboutCall), in other words within the DLL there's a kind of 'Select Case' statement that determines, based upon the value of nServiceID, which internal function to call. Further information is passed into, and returned from, this function via the second parameter - lpStruct. lpStruct from the Visual Basic end is any structure (Type) defined in the module AboutBoxMainRoutines, for example to find out some extra information on the mouse it might be a VBMOUSEINFO type:

' Mouse Info type.

Const ID_MOUSE = 1

Type VBMOUSEINFO

    nSize             As Integer  ' Size of this structure - same for all passed TMS structures.

    bMouseExists      As Integer  ' VB True if the mouse exists else false.

    nNumMouseButtons  As Integer  ' The number of mouse buttons on the mouse.

    nMouseCommPort    As Integer  ' The com port the mouse is connected to.

End Type

Note that an instance of this type is passed into the function 'As Any'. For a structured type like this that means 'by reference' (by pointer (or address) in other words). The DLL 'knows' what type of structure should be passed and fills it in accordingly so that when the function returns the information required is already 'in' the passed type! The DLL 'knows' about the type because the nServiceID parameter indicates what lpStruct points to. In the example above a service ID of ID_MOUSE indicates that a VBMOUSEINFO is being passed by reference in the second parameter.

Initialization

Each type has a member called nSize. This member must be set to the size of the type being passed (of which it is a member). This is best done using the Len() function, e.g. tSomeType.nSize = Len(tSomeType). Failure it initialize the type correctly will cause the call to fail

See Also

Other Interesting Stuff

The Custom DLL


The 'Message Blaster'

The Message Blaster custom control used within the Blowup application is available in at least two sources and forms. The first - that used in the application on the VBITS CD is available from Compuserve and the Microsoft Developers Network (MSDN) (complete with examples of how to use it). It is a general, although very flexible,  sub-classing type .VBX. It allows its user to sub-class any window for any message. It also allows its user to intercept messages both before and after Windows has processed them (a feature used in this application). The source code is also included on the MSDN CD (we do not know if it is available on Compuserve).


hmemcpy

The hmemcpy function copies bytes from a source buffer to a destination buffer. The amount of memory copied is also provided. This function supports huge memory objects (that is, objects larger than 64K). Note that the result of the hmemcpy function is undefined if the memory areas identified by 'Destination' and 'Source' overlap.

See Also

Pointers


lstrcpyn

The lstrcpyn function copies a specified number of characters in a string to a buffer. Note that the terms buffer and string here refer to areas of memory treated as though they contain 'C' type string data, for example a NULL byte (a character containing the value 0) would signify the end of the source data irrespective of the number of bytes requested by the last 'number of bytes to copy' parameter.

See Also

Pointers


 The About... Custom DLL

The ABOUTDLL DLL

This DLL contains a set of sub-routines which are usually used to create a set of information used by TMS 'About...' boxes. The source code is usually not available outside of TMS - however, if you're interested in acquiring it then please contact TMS directly.

These routines accept Visual Basic types (called structures in 'C') which are passed in from the Visual Basic side of this application. A typical 'Type' might look like this:

' Mouse Info type.

Const ID_MOUSE = 1

Type VBMOUSEINFO

    nSize            As Integer  ' Size of this structure - same for all passed TMS structures.

    bMouseExists     As Integer  ' VB True if the mouse exists else false.

    nNumMouseButtons As Integer  ' The number of mouse buttons on the mouse.

    nMouseCommPort   As Integer  ' The com port the mouse is connected to.

End Type

This is the type required to gather extra information about the mouse.

The routine to which this type is passed is called bAboutCall. This DLL function is passed an integer (which 'tells' the routine what is being passed in its other formal parameter which is the instance of the type itself. The 'C' based DLL also has a definition of each of the types which may be passed. Here's the VBMOUSEINFO type in 'C':

#define ID_MOUSE    1

typedef struct

{

    int  nSize;

    BOOL bMouseExists;

    int  nNumMouseButtons;

    int  nMouseCommPort;

} VBMOUSEINFO;

typedef VBMOUSEINFO FAR * LPVBMI;

You can see just how similar they are (note that in Visual Basic 4.0 a Boolean type has been added. This wasn't used in the definition of the Visual Basic version of VBMOUSEINFO (bMouseExists) as it was still a little unclear as to what may be stored in a Boolean at this time).

The 'type id' is used in a switch statement (like a Select Case) to determine what internal function should be called to service this call:

// Mouse information from mouse's device driver.

case ID_MOUSE:

     bRes = bInternalGetMouseExtraInfo((LPVBMI)lpStruct);

     break;

The code above is again taken from the DLL and is written in 'C'. bInternalGetMouseExtraInfo() is the function that actually does the work of finding out about the mouse - it is 70 lines of 'C' and assembler.

See Also

TMS

License


VBRUN100.DLL, VBRUN200.DLL, VBRUN300.DLL
Visual Basic DLLs

The DLL files VBRUN100.DLL, VBRUN200.DLL and VBRUN300.DLL are some of the dynamic link libraries required by the run-time version of Visual Basic. They are NOT used by VB.EXE. When this help file was being authored it was not none whether or not this naming convention will be used to similarly 'label' the Visual Basic 4 run-time.


DLL
Dynamic Link Library (DLL)

A DLL is a library of procedures (functions and sub-routines) which may be used by any number of applications, in this respect they are no different to 'statically linked' libraries. However, in static linking the executable gets its own copy of the library code inserted into it by the linker. In dynamic linking the linker simply inserts a reference to the required library file (DLL) - the actual link then is not carried out at 'link time' but at run-time. The main advantages or dynamic linking are:

1. Code may be shared (this allows for a certain level of object orientation)

2. Code may be upgraded more easily (by providing a later copy of a DLL)

3. Application executables (as files) are smaller (as most of their code is in DLL files)

4. DLLs may be used for 'inter-process' communication (as more than one application can call the same code information may be shared)

The disadvantages are few and as far as the Visual Basic coder goes are really:

1. A DLL file may be deleted and yet your program, up to a point will run!

2. Although a DLL file may be missing your link to it (as a Visual Basic programmer) is carried out when the Visual Basic language interpreter first encounters, and therefore has to evaluate, a statement which contains a call to the DLL

3. It is difficult to determine (as a program and as a user) what version of a DLL you have linked to, i.e. you may have linked to an old buggy version by mistake

See Also

TMS


VBMOUSEINFO

This is a 'type', or in 'C' language terms, a structure, used by the ABOUTDLL DLL written by TMS.


As Any

As any tells Visual Basic to NOT check types across a function/sub-routine call. When applied to a Type it means, "take this variable's address and pass that to the called DLL function", i.e. pass the type by reference.


 ByVal

This Visual Basic keyword means 'pass the evaluation of this object', for example if a Visual Basic sub-routine looked like this:

Sub SomeSub(ByVal X As Integer)

X = X + 1

End Sub

and was called like this:

Dim n As Integer

n = 1

SomeSub n

then n is evaluated (1). The result of this evaluation is used further in this expression as it is passed to SomeSub. The result of the evaluation is placed, in this example, in an integer sized piece of memory (a so called anonymous object (as it has no identifier awarded to it)). The address of this integer is then passed to SomeSub. So, SomeSub always receives an object by reference but not always your original object! To make this clearer imagine what must happen when the result of a complex expression or even a constant is passed, e.g. what happens when we  SomeSub A + B or SomeSub 10 in a program?


 How lstrcpyn and hmemcpy Work

Both lstrcpyn and hmemcpy work in the same way. They copy data from one area of memory to another. In both cases the addresses of these two areas are given as pointers.

The result of this operation using lstrcpyn() is this (in destination)

Whereas using hmemcpy() it's this

The difference (at this level) then between these two functions is that hmemcpy copies all the source data whereas lstrcpyn copies only up to, but not including, any byte which contains a 0 (zero). lstrcpyn does this because it normally works on string data not arbitrary data as hmemcpy does. In other words a 0 marks the end of a string to lstrcpyn whereas to hmemcpy it's just another byte value. You can now see why lstrcpyn doesn't work properly in our Visual Basic application, a WINDOWPOS structure can contain a byte whose value is zero. This would stop lstrcpyn from copying any more information to our destination structure. The destination structure is only partially complete!

See Also

hmemcpy

lstrcpyn


Pointer

A pointer is a numeric value which equates to an address in memory. The 'C' programming language supports a scalar type that is a pointer, i.e. 'C' has intrinsic support for pointer types.

See Also

How lsrtcpyn and hmemcpy work


TMS @ VBITS
The Mandelbrot Set at The Visual Basic Insiders Technical Summit

The Mandelbrot Set (International) Ltd are presenting two talks at this, the first London VBITS. 'Using the Windows API in Visual Basic' and 'Team Programming with Visual Basic'. Both talks take place on the afternoon of February 1st 1995 in the Grand Hall of the Wembley Conference and Exhibition Centre. See you there!


 The Tools We Used

Techie people often like to know how things were put together, well for your information this is what we used.

As well as Visual Basic 3.0 Professional we used Microsoft Visual C++ version 1.51 (without MFC support) to build the example DLL - the DLL was written in plain 'C', NOT C++ (if you want to know why we'd prefer 'C' over C++ read Peter's book!). All the necessary files are included to rebuild the blowup samples DLL (DLL.DLL).

The error handlers were fitted to the Visual Basic code using AutoCoder - a single tool that is part of TMS Tools v1.1

This help file was put together using ForeHelp (which we acquired as an optional extra to Borland's C++ version 4.0).

Microsoft's PowerPoint version 4.0 was used to build the actual presentation.


 Other Interesting Stuff

About

Note that in the About application that we use many API calls - there are lots more being made within the DLL which of course you cannot easily see. One call we thought we'd point out to you however is pretty special as it's a little interesting:

Declare Function ExtractIcon Lib "Shell" (ByVal hInst As Integer, ByVal lpFileName As String, ByVal nIconID As Integer) As Integer

The ExtractIcon API is part of the 'SHELL' DLL which is mainly provided for writers of such things as Program Manager and File Manager - 'shells' in other words! See the DoIcon() routine (and of course the SDK help file) in the example application to see how it's used.

One other API in the About application is not in the 'core' set.

Declare Function SystemHeapInfo Lib "TOOLHELP.DLL" (shi As SYSHEAPINFO) As Integer

This function is part of the TOOLHELP DLL. We use it instead of the more familiar GetFreeSystemResources() functions that you may see being used. The TOOLHELP library is the recommended way to find this sort of information out. See you SDK documentation for much more on the TOOLHELP library.

Blowup

The blowup application does some pretty good on screen drawing using a 'screen device context' - this means that it can draw anywhere on the screen! It uses the API DrawFocusRect() to do its rectangle drawing as this is an easy function to use. It also doesn't require you to set pen widths etc as it draws always with a logical pen that is width one pel. Note that even this function is not the best to use for FAST line drawing.

See your SDK documentation for more on the various APIs used within this application.

Conventions

Note that we have used keywords like Private as a prefix to form level event handlers and procedures where appropriate. In future versions of Visual Basic form level procedures may be callable from outside of the form module itself unless prefixed with 'Private' - an implied 'Public' interface in other words. Note also that we have often used ByVal as a formal parameter modifier, i.e. procedures called from within Visual Basic code that are themselves written in Visual Basic code. This is part of TMS's coding standards and is an attempt to 'protect' the actual parameter from change, i.e. to make it safe against assignment within the body of the called routine.


SDK

SDK stands for 'Software Development Kit' - a pretty generic term usually. In Windows programming circles however the 'SDK' refers to the low-level tools used to do Windows programming. An actual SDK used to be shipped by Microsoft which contained information on the many Windows' APIs and methods of programming. These days that information ships with toolkits like Microsoft's Visual C++ etc.


All Required Files
 Required Files

'About' Required Files

The 'About Box' demonstration is made up of the following files:

aboutbox mak     Visual Basic project file

abtmain  frm     Main/First form

abtmain  frx     Graphic file

aboutbox frm     First 'About Box' form

aboutbox frx     Graphic file

sysinfo  frm     Detailed 'About Box' form

aboutbox bas     Helper routines

aboutbox exe     Built executable

aboutdll dll     TMS 'About Box' DLL

'Blowup' Required Files

The 'Blowup' demonstration is made up of the following files:

blowup   mak     Visual Basic project file

blowmain frm     Blowing up form

blowmain frx     Graphic file

blowup   bas     Helper routines

blowup   exe     Built executable

msgblast vbx     Message Blaster custom control

dll      dll     Helper/Example DLL

dll      c       DLL 'C' source code

dll      mak     DLL project/'make' file

dll      def     DLL module definition file

Files common to both demonstrations

help     hlp     This help file

modgen   bas     Common routines

constant txt     As supplied with Visual Basic

Various Other files

team     doc     Team programming paper

team     ppt     Team programming PowerPoint slides

api      doc     API paper

api      ppt     API PowerPoint slides

readme   wri     General readme file